Propagate only what changed, and replace a directory with a symlink - #62

Reviewer notes.

How the two causes were separated. The failing set is 11 repositories. Comparing all 63 source symlink paths against each target's trees splits them cleanly:

Arc, Studio and Lens have no conflict and are not failing. Arc was failing in earlier runs and dropped out once its .github/instructions was converted — that is the shifting-subset behaviour the issue reported, explained.

Note .claude/commands is a tree in the source too (it holds per-file symlinks), so a target having it as a tree is correct. It looks like a conflict and is not; the comparison excludes it by construction because it compares against source paths whose mode is 120000.

Volume, concretely. Before: every propagated file uploaded to every target on every run. After: only the files whose blob sha or mode differs. On a typical run that is one file rather than 63-plus, per repository, which is what puts the rate limit out of reach rather than merely further away.

What I verified, and how. The step-3/step-4 logic was extracted and run against a simulated tree where one file matches, one differs, and one path is a directory in the target. It selected exactly the two differing files, flagged only the directory, and emitted {"path":".github/instructions","mode":"040000","type":"tree","sha":null} ahead of the additions. bash -n is clean.

What I could not verify. I have not run this against the real API. Two things to watch on the first run:

1. That the tree API accepts a sha: null delete and an add for the same path in one call. It is the documented way to delete an entry under a base_tree, and the delete is ordered first, but same-path delete-then-add in a single tree is the part I am inferring rather than observing.
2. That .agents/PROJECT.md — the file the rate-limited jobs died on — is genuinely per-repository content and not something propagation should be overwriting at all. It is the one propagated path whose name suggests it is project-local, and general.md describes .agents/PROJECT.md as living in the consuming project. Worth a look independently of this fix; I have not changed its handling.

If (1) turns out not to work, the fallback is two tree calls — delete, then add on the resulting tree — which costs one extra request per affected repository and only on the conversion run.